编程的时候，如果要跟某个IP建立连接，我们需要调用操作系统提供的 socket API。

socket 在操作系统层面，可以理解为一个文件。我们可以对这个文件进行一些方法操作。

在建立好连接之后，这个 socket 文件就像是远端机器的 "代理人" 一样。比如，如果我们想给远端服务发点什么东西，那就只需要对这个文件执行写操作就行了。

 那写到了这个文件之后，剩下的发送工作自然就是由操作系统内核来完成了。

既然是写给操作系统，那操作系统就需要提供一个地方给用户写。同理，接收消息也是一样。这个地方就是 socket 缓冲区。

也就是说一个socket ，会带有两个缓冲区，一个用于发送，一个用于接收。因为这是个先进先出的结构，有时候也叫它们发送、接收队列。

如果想要查看 socket 缓冲区，可以在linux环境下执行 netstat -nt 命令。

 这上面表明了，这里有一个协议（Proto）类型为 TCP 的连接，同时还有本地（Local Address）和远端（Foreign Address）的IP信息，状态（State）是已连接。

我们在使用TCP建立连接之后，一般会使用 send 发送数据。

 上面是一段伪代码，仅用于展示大概逻辑，我们在建立好连接后，一般会在代码中执行 send 方法。那么此时，消息就会被立刻发到对端机器吗？

答案是不确定！执行 send 之后，数据只是拷贝到了socket 缓冲区。至 什么时候会发数据，发多少数据，全听操作系统安排。

 在用户进程中，程序通过操作 socket 会从用户态进入内核态，而 send方法会将数据一路传到传输层。在识别到是 TCP协议后，会调用 tcp_sendmsg 方法。

在 tcp_sendmsg 中， 核心工作 就是将待发送的数据组织按照先后顺序放入到发送缓冲区中， 然后根据实际情况（比如拥塞窗口等）判断是否要发数据。如果不发送数据，那么此时直接返回。

前面提到的情况里是，发送缓冲区有足够的空间，可以用于拷贝待发送数据。如果发送缓冲区空间不足，或者满了，执行发送，会怎么样？这里分两种情况。

 当发送缓冲区满了，如果还向socket执行send：

如果此时 socket 是阻塞的，那么程序会在那干等、死等，直到释放出新的缓存空间，就继续把数据拷进去，然后返回。

如果此时 socket 是非阻塞的，程序就会立刻返回一个 EAGAIN 错误信息，意思是  Try again , 现在缓冲区满了，你也别等了，待会再试一次。

我们可以简单看下源码是怎么实现的。还是回到刚才的 tcp_sendmsg 发送方法中。

接收缓冲区也是类似的情况。当接收缓冲区为空，如果还向socket执行 recv

如果此时 socket 是阻塞的，那么程序会在那干等，直到接收缓冲区有数据，就会把数据从接收缓冲区拷贝到用户缓冲区，然后返回。

如果此时 socket 是非阻塞的，程序就会立刻返回一个 EAGAIN 错误信息。

首先我们要知道，一般正常情况下，发送缓冲区和接收缓冲区 都应该是空的。

如果发送、接收缓冲区长时间非空，说明有数据堆积，这往往是由于一些网络问题或用户应用层问题，导致数据没有正常处理。

就会触发四次挥手

2、如果发送缓冲区有数据时，执行close了，会怎么样？

此时，还有些数据没发出去，内核会把发送缓冲区最后一个数据块拿出来。然后置为 FIN。

socket 缓冲区是个先进先出的队列，这种情况是指内核会等待TCP层安静把发送缓冲区数据都发完，最后再执行 四次挥手的第一次挥手（FIN包）。

有一点需要注意的是，只有在接收缓冲区为空的前提下，我们才有可能走到 tcp_send_fin() 。而只有在进入了这个方法之后，我们才有可能考虑发送缓冲区是否为空的场景。

socket close 时，主要的逻辑在 tcp_close() 里实现。先说结论，关闭过程主要有两种情况：

如果接收缓冲区还有数据未读，会先把接收缓冲区的数据清空，然后给对端发一个RST。

如果接收缓冲区是空的，那么就调用 tcp_send_fin() 开始进行四次挥手过程的第一次挥手。